Design Pattern-Based Extension of Class 
Hierarchies to Support Runtime Invariant 

Checks 

John Lasseter and John Cipriano 

Fairfield University, Fairfield CT 06824, USA 
jlasseterOf airfield. edu, johnmikecipOgmail . com 

Abstract. We present a technique for automatically weaving structural 
invariant checks into an existing collection of classes. Using variations on 
existing design patterns, we use a concise specification to generate from 
this collection a new set of classes that implement the interfaces of the 
originals, but with the addition of user-specified class invariant checks. 
Our work is notable in the scarcity of assumptions made. Unlike previous 
design pattern approaches to this problem, our technique requires no 
modification of the original source code, relies only on single inheritance, 
and does not require that the attributes used in the checks be publicly 
visible. We are able to instrument a wide variety of class hierarchies, 
including those with pure interfaces, abstract classes and classes with 
type parameters. We have implemented the construction as an Eclipse 
plug-in for Java development. 

1 Introduction 

Several, if not most, mainstream languages include features to support object- 
oriented programming, yet most of these (C++, C#, Java, Python, etc.) lack 
any native language support for the specification and runtime checking of class 
invariants. While it is usually easy enough to implement the invariant predicates 
themselves, manual addition imposes further requirements in order to implement 
the operational requirements of invariant checking and to handle the interplay of 
invariant specification and inheritance. Class invariants are further troublesome 
in that they involve direct access to an object's attributes. This makes manual 
addition particularly unappealing, as the available choices are invasive with re- 
spect to the original interface and implementation (to which we may not have 
access), compromise encapsulation, and are error-prone if done manually. 

This paper presents a lightweight, non-invasive technique for automatically 
extending a collection of class definitions with a corresponding collection of struc- 
tural invariant checks. The invariants are given as a stand- alone specification, 
which is woven together with the original source files to produce a new collection 
of drop- in replacement classes that are behaviorally indistinguishable from the 
originals in the absence of invariant- related faults but will expose such faults in 
a way that the original classes do not. Each replacement is defined to be a sub- 
class (indeed, a subtype d ) of the original class whose functionality it extends, 
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and it can thus be substituted in any context in which the original occurs. The 
generation is itself completely automatic, and the incorporation into a test har- 
ness or other program is nearly seamless. We focus here on the Java language, 
a choice that complicates the overall strategy in some ways while simplifying it 
in others. 

2 Background and Related Work 

A class invariant is a conjunction of predicates defined on the values of an 
object's individual attributes and on the relationships between them. It char- 
acterizes an object's "legal" states, giving the predicates that must hold if the 
object is to represent an instance of that abstraction. Usually, a class invariant 
is given in conjunction with the contracts for each publicly-visible method of 
a class, i.e., the preconditions that must hold on arguments to each method 
call and the consequent guarantees that are made as postconditions upon the 
method's return. Unlike the contracts, however, a class invariant is a property 
concerning only an object's data values, even (especially) when those values are 
not publicly visible. An invariant must hold at every point between the object's 
observable actions, i.e. upon creation of any object that is an instance of this 
class and both before and after every publicly- visible method call |2I3) . At other 
points, including non-visible method calls, it need not hold, and runtime checks 
are disabled in this case. Further, since runtime invariant checks can impose a 
non-trivial performance penalty on a system, in general, it is desirable to have a 
mechanism for leaving the checks in place during testing, while removing them 
from a final, production system. Finally, there is an important interplay between 
the subtype relation (which determines when one object can safely be substi- 
tuted in a context calling for another [T]) and class invariants: if B is a subtype 
of A (as well as a subclass) then the invariant for B must include all of the 
constraints in ^4's invariant |2l3j . 

Some languages offer native support for invariant checking, but for Java and 
other languages that lack this, including such checks is challenging. A common 
approach is to make use of the language's assertion mechanism, by including 
assertions of the invariant at the end of each constructor body and at the begin- 
ning and end of the body of each public method [2]. If the language's assertions 
mechanism is used, disabling the checking functionality after testing is usually 
quite easy. However, this approach carries the disadvantage of requiring the class 
designer to code not only the predicates themselves but also an explicit handling 
of the inheritance requirements and the full execution model, discussed above. 
Both of these tasks must be implemented for each invariant definition, in each 
class. 

To avoid the implementation burden of the assertions approach, we can use a 
tool that generates the invariant checks from either specialized annotations of the 
source code |4|5I6| or reserved method signatures |7I8I9| . Essentially, such tools 
offer language extensions to resemble native support for invariant definitions. 
In comparison to assertion-based approaches, they eliminate the requirement of 
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implementing the execution model, a clear advantage. As with the assertions 
approach, annotation approaches are invasive, in that they require modification 
of the original source code. More substantially, the approach generally requires 
the use of a specialized, nonstandard compiler, whose development may not keep 
up with that of the languag^] 

Instead, we can view the addition of runtime invariant checking across a class 
hierarchy as a kind of cross-cutting concern, i.e. code that is defined across sev- 
eral classes and hence resists encapsulation. Under this view, it is natural to 
approach this problem as one of aspect-oriented programming (AOP) in 
which we can use a tool such as AspectJ [12] to define the checks separately 
as aspects. The entry and exit points of each method become the join points, 
the point cuts are inferred from a class's method signatures, and the invariant 
check itself becomes the advice |13ll4j . Unlike annotation-based approaches, as- 
pect weaving can be done without the need for a non-standard compiler, either 
through source code transformation or byte code instrumentation [15] . However, 
the AOP approach also presents several difficulties. For example, Balzer et al. 
note that mainstream tools such as AspectJ lack a mechanism to enforce the 
requirement that the definition of a class's invariant include the invariant of its 
parent class [IB]. It is possible to write invariant checking "advice" so that it 
correctly calls the parent class's invariant check, but this must be done manu- 
ally (e.g. [13] ). A similar problem occurs in implementing the correct disabling 
of checks on non-public calls. Lastly, because aspects cannot in general be pre- 
vented from changing an object's state, the weaving of additional aspects may 
compose poorly with the aspect that provides the invariant check [17116118] . It 
is possible that another aspect could break the class invariant, and since inter- 
leaving of multiple aspects is difficult to control, it is possible the two aspects 
could interleave in such a way as to make the invariant failure go undetected. 

The work closest in spirit to our own is the design pattern approach of Gibbs, 
Malloy, and Power ; 1 19121)1 . Targeting development in the C++ language, they 
present a choice of two patterns for weaving a separate specification of invari- 
ant checks into a class hierarchy, based on the well known decorator and visitor 
patterns [21]. However, the decorator approach involves a fairly substantial refac- 
toring of the original source code. Moreover, the authors note that this technique 
interacts poorly with the need to structure invariant checks across a full class 
hierarchy. The rcfactoring in this case is complex, and it requires the use of 
multiple inheritance to relate the decorated classes appropriately, making it un- 
suitable for languages such as Java, which support only single inheritance. Their 
alternative is an application of the visitor pattern, in which the invariant checks 
are implemented as the visit methods in a single Visitor class. This pattern usu- 
ally requires that the classes on the "data side" implement an accept method, 
which is used to dispatch the appropriate visit method, but in their use of it, 
only the top of the class hierarchy is modified to be a subclass of an "invari- 
ant facilitator" , which handles all accept implementations. However, successful 



1 For example, JML has not seen active development since version 1.4 of the Java 
language [TO] . 
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implementation of the visit methods rests on the assumption that all fields are 
cither publicly visible or have their values readily available through the existence 
of accessor ("getter") methods. Unless the language simply lacks a mechanism 
to hide this representation (e.g. Python), such exposure is unlikely to be the 
case, as it violates encapsulation, permitting uncontrolled manipulation of an 
object's parts, either directly or through aliasing [2j. 

The central thesis of our work is that, under assumptions common to Java 
and other statically-typed 00 languages, these limitations — source code modi- 
fication, multiple inheritance, and public accessibility of fields — are unnecessary 
for a design-pattern approach. The remainder of the present paper shows how 
to relax them. 

3 Weaving Invariant Checking from Specifications 

Our approach draws from the Gibbs/Malloy/Power design pattern efforts and 
from ideas in AOP in the treatment of invariant specifications as a cross-cutting 
concern. We begin with an assumption that the class invariants are given in 
a single specification file, separate from classes that they document. Each con- 
straint is a boolean- valued Java expression, with the invariant taken to be the 
conjunction of these expressions. We assume (though do not hope to enforce) 
that these expressions are free of side effects, and that the invariant given for a 
child class does not contradict any predicates in inherited invariants. Otherwise, 
the particulars of the specification format are unimportant. The current version 
of our tool uses JSON [55], but any format for semi-structured data will do. 

We focus on the Java programming language, which means that we assume a 
statically-typed, object-oriented language, with introspective reflection capabil- 
ities, support for type parameters in class definitions, single inheritance (though 
implementation of multiple interfaces is possible), and a uniform model of virtual 
method dispatch. We make some simplifications of the full problem. Specifically, 
we work only with synchronization- free, single-threaded, non-final class defini- 
tions, and we consider only instance methods of a class that admit overriding, 
i.e., non-static, non-/ina^]method definitions. We do not consider anonymous in- 
ner class constructs nor the lambda expressions planned for Java 8 |23j . Finally, 
we assume a class's field visibility grants at least access through inheritance (i.e. 
protected accessbility or higher) . This last is made purely for the sake of simpli- 
fying the technical presentation, since, as discussed in section [5] introspection 
makes it easy to handle variables of any accessibility. 

3.1 An Inheritance-Based Approach 

As a first effort, we will try an approach that leverages the mechanism of in- 
heritance and the redefinition of inherited method signatures through subtyping 

2 The final keyword has two uses in Java: to declare single-assignment, read-only 
variables and to prohibit extension of classes or overriding of methods. The latter 
form is equivalent to the sealed keyword in C#, and it is this usage we avoid here. 
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public class A'<T A /> extends A<S A i> { 

private int (5 = 0; 

public A{r a { 
super 
S = 8 + 1; 

} 

public r /A Sa^Sa & { 

<t>lO; Tf A X = super. / A ) ; cj> 2 () J 
return x ; 

} 

private boolean mi?0 { return ; } 

private void 0i O { 
if (<5 == && MnvO) 

{ handle invariant failure ) 
5=5+1; 

} 

private void { 
5=5-1; 

if (<5 == && \invO) 

( handle invariant failure ) 

} 

} 

Fig. 1. Inheritance-based generation of invariant checks 



polymorphism. The idea is to derive from a class and its invariant a subclass, 
in which we wrap the invariant in a new, non-public method (perhaps with ad- 
ditional error reporting features), similar to the "repOif' approach advocated 
by Liskov and Guttag [2|. To this new subclass, we also add methods <j>\ and 
4>2 to handle the checking tasks at (respectively) method entry and exit points, 
and we use these to define constructors and overridden versions of every public 
method. 

Let A be a class, with parametric type expression Ta defined on type pa- 
rameters Sa-, field declarations r a, invariant pa, constructor definition A(ta 
and public method Tf fiajz). 

public class A<Ta> { 
r a J ; 

public AirZi') { . . . } 
public T fA Sa^ Sa )j) { ... } 

} 

We extend A with runtime checking of pA by generating the subclass in Fig. [l] 
where Ta> and Sa' are identical to Ta and Sa (respectively) , except perhaps for 
renaming of type parameters (i.e., they are a-equivalent). 

For each constructor in A' , the body executes the "real" statements of the 
corresponding superclass constructor, followed by a check of pa, whose execution 
is itself controlled by the 4>2 method. Likewise, the body of each public method 
/a wraps a call to the superclass's version between checks of pa, with execution 
controlled by the 4>\ and methods. If /a returns a value, then this value 
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is captured in the overridden version in a "result" variable, \. A method or 
constructor call is publicly-visible precisely when the call stack depth on a given 
A! object is 0, and this value is tracked by the additional integer- valued field 5. 
The 4>\ and <p2 methods increment/decrement 8 as appropriate, evaluating pa 
only if 5 = 00 

The inheritance-based approach suggests an easy mechanism for reusing code 
while adding the necessary invariant checks and capturing the distinction be- 
tween publicly-visible and inner method calls. For the user, the burden consists 
of replacing constructor calls to A with the corresponding calls for A' . This may 
be an excessive requirement when A objects are used in production-level code, 
but in many settings where invariant checking is desirable, such constructor calls 
are limited to only a handful of sites. In the JUnit framework, for example, in- 
tegration of A' objects into unit tests for A is likely quite simple, as object 
construction occurs mainly in the body of a single method, setUp. 

Note the assumptions of uniform polymorphic dispatch and non-final decla- 
rations here. If a class cannot be extended {e.g. String and other objects in the 
java.lang package), then construction of a subclass that implements the invariant 
checks is obviously impossible. Similarly, a method whose dispatch is statically 
determined cannot be transparently overridden, and if declared final, it cannot 
be overridden at all. In many languages (notably, C# and C++) the default 
convention is static dispatch, with dynamic binding requiring an explicit virtual 
designation; in such cases, the inheritance construction is far less convenient and 
may be impossible without some refactoring of the original source code. 

Unfortunately, our first attempt fails in two critical ways, which becomes 
apparent when we attempt to construct the invariant-checking extension across a 
hierarchy of class definitions. First of all, the inheritance hierarchy of a collection 
of objects requires a corresponding structure in the composition of invariant 
checks. This problem is very similar to the one encountered in the "decorator" 
approach of [3U] , but the multiple- inheritance solution given there is unavailable 
in a single-inheritance language such as Java. Consider a class B that is a subtype 
of A (written B <: A): 

public class B<T B > extends A<Sb>{ 

public B(tF^) { ■ • ■ } 
public r gg gia gB h { ... } 

} 

Figure [2] depicts the problenj^J The invariant for a B object, invB, must include 
the A invariant — i.e., invs — inv^ApB- However, a B' object cannot access the 
fields of its associated B object through inheritance and also reuse the function- 

3 In the presence of concurrency, we would need a more sophisticated mechanism; 
keeping track of the call stack depth on an object for each thread, synchronizing all 
method calls on the object's monitor lock, and so on. 

4 There and throughout this paper, we write [S/t] T to denote the substitution of 
type expression r for the type parameter S in expression T, and use the shorthand 
[Si/n, S2/T2] T to denote the composition of type expressions [Si/t\] [S2/V2] T. 
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A < T A> 

ra 



A'<T\> 

A 

boolean inv^ ( ) 

A 



[s A ,niT A , ? 



B < T B> 

boolean invg ( ) 



Fig. 2. Design flaw in the naive inheritance approach 



ality of the invA method. We might choose to have B' descend from A' instead, 
but this only works if all fields in B are publicly accessible. As discussed above, 
this is unlikely to be the case. 

The second, related failure is that inheritance does not facilitate a correct 
binding of the type parameters. Again, this is clear from Fig. [2} An instantiation 
of B supplies a type r to the parameters Sb, which is used in turn to bind 
the parameters Sa with argument [Sg/r, Sa/Sb] Ta- When we instantiate B' 
instead, this same r binds the parameters Sb 1 , with the resulting chain of ar- 
guments binding ^4's parameters Sa as [Sb 1 /t, Sb / Sb 1 , Sa/ Sb]Ta- For correct 
use of the A' invariant check in this B'(t) object, we would need to bind the 
type parameter of A', Sa>, in the same way we do A's parameter, Sa', i-e. with 
argument [Sb'/t, Sa>/Sb>, Sa/Sa 1 ] Ta, a binding that cannot be ensured, unless 
B' is a subclass of A'. 

3.2 Exposing the Representation 

Though unsuccessful on its own, we can use the inheritance approach of Section 
|3.1| as the basis for an auxiliary pattern, which we call an exposure pattern. The 
idea is to construct from the original hierarchy a corresponding set of classes that 
offers the interface of the original collection and in addition, a controlled exposure 
of each object's representation. The machinery for checking the invariants is 
factored into separate classes, as discussed in Section [3T3| below. 



«bind» 

[S A /S A ,]T A . 



«bind» 

[S A IS B ]T A 







B<T B > 
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Consider a class definition 

public class A<Ta> { 
Ti ai; ... T k a k ; 
public A(tJ~$) { ■ ■ ■ } 
public Tf A f A (<r/ A h { ■ ■■ } 

} 

We derive the exposure interface 

public interface I Ae<T a ii> { 
Ti 7 01 () ; 

T m 7a m O ; 

} 

and exposed class 

public class A^<T 4 /> extends A<S A /> implements I A^<S A /> { 
private int 5=0; 
private void <piO { ■■•} 
private void <f>%0 { ■ ■ ■ } 
protected boolean invdnvV v) { ■ ■ ■ } 

public A e Cta y) { 

super (y) ; 8 = 6+1; <p2 O ; 

} 

public Tf A fA<.Cf A fa { 

<t>iO; Tf A X = super. /a(1/) ; 4>2 O ; 
return \ '> 

} 



public T\ "f a . (){ return ai ; } 
public r m 7a m (){ return ; } 



where T^/, T_a» and S 1 ^', S^" are a-equivalent to and S^, as above. Note 
that the fields a\ . . . a rn include all of the original a\ . . . ak and perhaps others, 
as discussed on page[9j below. The constructors and public methods in Ae are 



overridden in exactly the same manner as in the A' class of Section 3.f and 
likewise the implementation of the 4>i{) and faQ methods. The representation 
exposure happens through the 7 0j (), a set of raw "getter" methods that expose 
each of the object's fields. In the presence of inheritance, the corresponding 
structure is realized not in the derived class but in the derived interfaces. Thus, 
for example, 

public class B<Tb> extends A<Sb > { 
ti 61 ; ... n b i; 
public B(tF^) { . . . } 
public t 9b }(a gB h { ... } 

} 
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IAe<T,,„> 



[S A /S B ]T A 



J -> 



«biud» 
[Sj S A JT A 



«bind» 
[S A J S A JT A „ 



«birut» 
IS A IS B 1T A 



Ae<T,,> 



[S A JS B ,JT A „ 



IBe<T b ,,> 



«bintl» 
[S B I S B J T B 



«bind» 
[S B J S„,]T B „ 



Be<T r ,> 



Fig. 3. Exposure pattern construction 



gives rise to the interface and class definitions 

public interface IB B <T B //> extends I A B <S B n> { 
Ti fb 1 O ; 

t„ 7i,„ C) ; 

} 

public class Be<T b /> extends B<S B r> implements IB B <S B r> { 

The construction is illustrated in Fig. [3J 



Correctness Since the type expressions in a class definition are copied to its 
exposed class and interface (perhaps with a- renaming of the parameters) , it is 
easy to see that 

Proposition 3.1 For any type expression t , an instance of a class A has type 
A<T(t)> if and only if Ae and IAe have types Ae<T(t)> and IAe<T(t)>, 
respectively. □ 

The construction of the accessor methods is less obvious. While we construct 
7 Qi () for each of the fields {oi, . . . ,»&}, we may need to construct others, as 
well, in case the invariant makes reference to any inherited fields for which 
we have not already constructed an interface. This can happen in the case of an 
incomplete specification of the class hierarchy and invariants. The simplest way 
to handle this is to include in the interface a j ai () for each declared field in the 
corresponding A classes and also for each variable that occurs without explicit 
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declaration in the the predicate pa- However, we can leverage the inheritance of 
interfaces to eliminate redundant declarations (though not implementations, as 
discussed below). 

To make the construction precise, we denote the free variables of the predicate 
pA by FV(pa), i-c. those variables that occur in pa without being explicitly 
declared in pa- Conversely, the bound variables in a class A, BV(A), are the 
instance fields declared in A. The following definition captures the notion of 
variables that are "free" in A through inheritance: 

Definition 3.2 Let P be a specification of a collection of classes and their as- 
sociated invariants. For a class A, the set of fields exposed through inheritance 
in A, 1(A), is defined by 



We use this to define the necessary method signatures in each exposure interface. 

Definition 3.3 Given class A and invariant pa, the body of IAe consists of 
the the signatures 



where each r ai is the declared type of cii . 

Definition 3.4 For a field, r a; aj, either declared in or inherited by a class A, 
we say that is successfully exposed for A if either 

— there is an interface IAe and subclass 

class Ae extends A implements IAe 

such that IAe includes a method interface 

* Ta; (); 

and for every Ae object o, o.^ ai () == o.a% 

— A is a subclass of C, and a, is successfully exposed for C. 

Given A and pa, the construction for IAe in Definition |3.3| and the accom- 
panying implementation Ae combine to give us the representation exposure we 
need for pa- In particular, 

Proposition 3.5 If x G FV(pa), then x is successfully exposed for A. □ 

Space Requirements The primary difference between the exposure pattern 
construction and the inheritance-based effort of Section 13.11 lies in the construc- 
tion of the exposure interfaces, whose inheritance structure is congruent to that 
of the original collection of classes. Like the earlier attempt, however, the collec- 
tion of exposed classes does not share this same relation, and as a consequence, 




, if A has no superclass specified in P 

1(C) U BV{C) U FV{p c ) ,if A<:C and C is specified in P 



IA E = {t^O; I Oi G BV(A)UFV(p A )\l(A)} 
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both approaches are subject to some unfortunate redundancy consequences. In 
particular, we cannot reuse code between distinct exposed classes, even when 
the classes they expose are related by inheritance. For example, if a class A con- 
tains fields ai and 02 and public method /() then the exposed class Ae must 
override /(), and it must include exposure methods j ai and j a2 , according to 
the interface IAe- If B <: A contains fields 61, 62, and method <?(), then it must 
override not only g() but also /(), with the body of the overridden /() identical 
to that in Ae- Likewise, it must implement not only the 7^ and 7t, 2 methods 
from the IBe interface, but also j ai and 7 a2 . 

Happily, all of this is easily automated, and it is reasonable to suppose the 
space overhead manageable. Note first that, with the exception of classes at the 
top of a specified hierarchy, the size of the interface generated for a class is 
proportional to the number of fields in that class. Recalling Definitions |3.2| and 
|3.3[ we can see that this is so because 

Proposition 3.6 Let C be a class included in a specification P. For every class 
A<:C,FV{ PA )\X{A) = BV{A). 

In other words, only for classes specified at the top of an inheritance hierar- 
chy will we ever need to generate additional 7 declarations in the corresponding 
interfaces. In all other cases, the accessor interfaces for inherited fields are in- 
herited from the corresponding parent interfaces. Hence, the space required to 
extend a collection of classes depends only on the size of each class and the 
depth of the inheritance relationship in the collection. Specifically, if we assume 
a bound of n new field and method definitions on each class and an inheritance 
depth of h, then the overall space growth is given by 

£(i>) = (£-)»=(^)»^<^ 

It is difficult to give a general characterization of either n or h, but there is reason 
to suspect that both are manageable values in practice. McConnell recommends 
a limit of 7 new method definitions in a class [21] ■ Shatnawi's study [25] finds 
no significant threshold value for h. Classes in the JDK's java. * and javax. * 
libraries implement anywhere from less than 10 to over 100 new methods, while 
the largest depth of any inheritance tree is 8. 

3.3 Adding the Invariant Checks 

As in Gibbs/Malloy /Power [20], we implement the runtime invariant checks 
themselves through an application of the visitor pattern |21j , in which the meth- 
ods implementing the invariant checks are aggregated into a single class (the "vis- 
itor" ) , with the appropriate method called from within the class being checked 
(the "acceptor"). Unlike their approach, however, our exposure pattern allows 
us to do this without modification of any part of the original source files, not 
even at the top of the inheritance hierarchy. 
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Suppose we have a class A<Ta>, with invariant pa- From these, we generate 
the exposed class Ae<Ta<> and the exposure interface IAe<Ta">, as in Section 
|3.2| The specification of pA and the access methods defined for IAe are used to 
generate an invariant checking "visitor" class: 

public class InvV { 

public <T Aj > void v A UA e <Sa, > obj) { 
Ti a\ = obj .71 ; 

T n a n = obj . 7^ C) ; 

{{ compute pa and return the result )) 

} 

} 

where Ta t and Sjl 2 are equivalent to Ta and its parameters Sa, as above. 

Runtime checking of pa is invoked in the Ae methods through calls to that 
class's inv method, which serves as the "accept" method, handling dispatch of 
the appropriate invariant check: 

public class A&<S A /> extends A<S A /> implements I Ae<S A /> { 
private int 5=0; 
private void 4>iO { ■■•} 

private void $2 (){••• } // (as defined in Scction |3.l[ l 
private boolean invilnvV v) { 

v.va (this) ; 

return i>.valid(); 

} 

} 

Note that each VaQ method in InvV takes an argument of type IAe and not 
Ae- This is necessary, because of the need to compose an invariant check with 
that of the object's superclass in each invariant method. For example, if we have 
B <: A, we define vg() as 

public <T B > void v B (I B B <S b> obj) { 
v A ( UA E <S B >) obj); 
{{ compute pb, us above )) 

} 

Since Ae and Be are not related by inheritance, it would not be possible to 
directly cast obj to its superclass's exposed version. Fortunately, the interface is 
all we need. 

Finally, although we structure our solution here according to the traditional 
visitor pattern conventions, we do not really need the full generality of that 
pattern. In particular, it is unnecessary to support full double dispatch, as we 
only need one instance of InvV, and no Vi() method will ever invoke a call 
back to the invQ method of an object (not even indirectly, since the <pi and 
4>2 methods in a class prevent a call to inv() if one is already running). Our 
implementation of this approach as an Eclipse plugin instead drops the InvV 
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parameter from every inv method, relying instead on a single, static instance of 
the invariant visitor: 

private boolean invO { 

InvVv = JnvV . getlnstance O ; 

} "' 

4 Example: Unit Testing 

Method contracts and class invariants are particularly useful in testing. In com- 
bination with test oracles, the use of runtime invariant and pre/post-conditions 
checks improves the exposure of faults as well as the diagnosability of faults when 
they are detected |26|27] . Our implementation as an Eclipse plug has proven use- 
ful in diagnosing invariant-related faults. 

For example, a simple List interface provides an abstraction for the list data 
type. A standard way to implement this is with an underlying doubly-linked list, 
in which we keep a pair of "sentinel" head and tail nodes, with the "real" nodes 
in the list linked in between: 

public abstract class AbstractList<T> implements List<T> { 
protected int size; 

} 

public class DLinkedList<T> extends AbstractList<T> implements List<T> { 
// inherited from AbstractList : int size 
protected DNode<T> head, tail; 

} 

Among other predicates, the invariant for DLinkedList requires that Vn ^ tail, 
n.next.prev = n. 

This was given as part of a project for the first author's data structures 
course, and among the student submissions received was this implementation of 
removef), in which the cur.prev pointer is not correctly updated: 

public boolean removed v) { 
DNode<T> cur = head. next; 
while Ccur != tail) { 

if (cur . data. equals Cv) ) { 

DKode<T> prev = cur.prev; cur = cur. next; prev.next = cur; 
size — ; 
return true ; 
> else 

cur = cur. next; 

} 

return false ; 

} 

A JUnit test suite failed to uncover this fault, passing this and the tests for 
12 other methods: 

public void testRemoveO { 

ls.addC'a") ; Is . addC'b" ) ; ls.addO'c"); Is . addC'd") ; Is . addC'a" ) ; Is . addO'd") ; 
int sz = Is . size C) ; 

assertTrueds.removeO'a")) ; assertTrue Cls . size () == sz - 1); 
sz = Is . size () ; 

assertTrue (! Is .remove ("**")) ; assertTrue Cls . size () == sz) ; 

} 
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From the original source code and a specification of invariants our tool gen- 
erates the classes and interfaces 

public interface IExposedAbstractList<T> { 
int _getSize () ; 

} 

public interface IExposedDLinkedList<T> extends IExposedAbstractList<T> { 
DNode<T> _getHead() ; 
DNode<T> _getTail() ; 

> 

public abstract class ExposedAbstractList<T> 

extends AbstractList<T> implements IExposedAbstractList<T> { . . . } 

public class ExposedDLinkedList<T> 

extends DLinkedList<T> implements IExposedDLinkedList<T> { . . . > 

public class RepOKVisitor { 

public <T> void visit (IExposedAbstractList<T> _inst) { ... > 
public <T> void visit (IExposedDLinkedList<T> _inst) { ... } 

> 

Objects in a JUnit test suite are constructed in the setUpQ method, and a simple 
modification was all that was needed to cause testRemove() to fail appropriately: 

protected void setUpC) { 

// Is = new DLinkedList<String> () ; 

Is = new ExposedDLinkedList<String> () ; 



5 Conclusion and Future Work 

The design pattern given here provides a fairly seamless approach for adding 
correct runtime invariant checking to a class hierarchy, through the construction 
of drop-in replacements that can be removed as easily as inserted. In addition 
to the core material presented here, there are a number of extensions possible. 

For example, the presentation in this paper relies on the assumption above 
that all fields in a class are accessible through inheritance. Happily, this is an 
easy if tedious limitation to overcome. If instead the field is declared with only 
intra-object or intra-class access (e.g. Java's "private"), we can use the intro- 
spective capabilities of the language to manufacture a locally- visible get method. 
To access a private field x, for example, our implementation generates a j x that 
handles the unwieldy details of Java introspection: 

private r -getXO { 

Class klass = this . getClass () ; Field field = null; 
while (field == null) { 
try { 

field = klass. getDeclaredFieldO'a;") ; field. setAccessible (true) ; 
} catch CNoSuchFieldException e) { 
klass = klass. getSuperclassO ; 

} 

} 

t x = null ; 
try { 

x = (t) field .get (this) ; 
} catch (IllegalAccessException e) { e .printStackTrace () ; throw new Error () ; } 
return x; 

} 



15 



Other extensions, such as the inclusion of anonymous inner classes, concur- 
rency, or final classes/methods, remain as open challenges. 

Finally, the work described here incorporates only the invariant checks, rather 
than full contracts, and it would clearly be useful to extend our design pattern 
to support this. While we conjecture that our technique is easily extendable to 
this purpose, the invariant checks present the most interesting problems, owing 
to their need for attribute access and hierarchical definition. Philosophically, 
ordinary unit testing already performs at least the behavioral components of 
contract checking, i.e. the checks of pre and post-conditions. What unit testing 
cannot do is determine whether the invariant continues to hold, as it is often 
impossible to access an object's fields. The difference lies in the fact that both 
pre and post conditions are inherently extensional specifications. They impose 
requirements on method arguments and return values, but on the object itself, 
all constraints are made upon the abstraction of the object, not the concrete 
implementation. That implementation — whose consistency with the abstraction 
is the core assertion of a class invariant — is by definition opaque to an object's 
user. 
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